home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001497_daemon _Wed Jun 30 00:13:06 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  2.     id AA21922; Wed, 30 Jun 93 00:13:08 MET DST
  3. Return-Path: <sugar!karl@one.neosoft.com>
  4. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  5.     id AA21918; Wed, 30 Jun 93 00:13:06 MET DST
  6. Received: from one.NeoSoft.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  7.     id AA05807; Wed, 30 Jun 1993 00:36:27 +0200
  8. Received: from sugar.UUCP by one.NeoSoft.com (5.67/1.34)
  9.     id AA03439; Tue, 29 Jun 93 17:34:58 -0500
  10. Received: by NeoSoft.Com (smail2.5)
  11.     id AA10920; 29 Jun 93 17:32:21 CDT (Tue)
  12. Subject: Re: browser execution
  13. To: sugar!bsdi.com!sanders@dxmint.cern.ch
  14. Date: Tue, 29 Jun 1993 17:32:20 -0500 (CDT)
  15. From: Karl Lehenbauer <karl@sugar.neosoft.com>
  16. Cc: www-talk@nxoc01.cern.ch
  17. In-Reply-To: <9306291821.AA05096@austin.BSDI.COM> from "Tony Sanders" at Jun 29, 93 01:21:01 pm
  18. X-Mailer: ELM [version 2.4 PL5]
  19. Content-Type: text
  20. Content-Length: 1469      
  21. Message-Id: <9306291732.AA10920@NeoSoft.Com>
  22.  
  23. > Marc wisely said:
  24. > > Having browsers execute code is *very* scary.  Servers generally run
  25. > > (or should run -- no reason not to) as userid 'nobody', and as such
  26. > > can cause practically no damage to anything.  In any case, server
  27. > > writers have much more knowledge about what's going to happen and what
  28. > > could happen while writing a server than client users do while just
  29. > > randomly clicking hyperlinks.  I don't see as there's any reason to
  30. > > think that client-side execution is safer.
  31. > 
  32. > In either case you should probably **seriously** think about running
  33. > in a chroot()'ed environment (which requires root perms to setup
  34. > of course).
  35. > 
  36. > Also, what about DOS environments (et.al.) where you have neither file
  37. > permissions nor chroot().  I think you are just SOL.
  38.  
  39. We are involved in some work on safe Tcl which will become part of
  40. active email under MIME.  The idea is that a subordinate Tcl interpreter
  41. can be created that is restricted only to operations that are safe --
  42. file access, forking, etc, are unavailable.  The "regular" Tcl interpreter
  43. can also export commands to the safe interpreter which are executed
  44. in the regular interpreter's environment -- totally analogous to an
  45. operating system's system calls.
  46.  
  47. I am about to post a secure Tcl experimenter's kit to comp.lang.tcl.
  48.  
  49. It would be a good candidate, IMHO, for delivering active HTML messages
  50. (i.e. programs) that can be executed safely, even though the sender
  51. isn't trusted.
  52.